Turning  "Desirements''  into  Requirements 

Charles  Court 

Because  we  are  humans,  everything  we  need  either  starts  or  finishes  with  something  we 
want.  As  students,  we  could  take  the  bus  to  school,  but  we  wanted  a  car.  Moreover,  we 
did  not  want  just  any  car.  A  Corvette,  a  Porsche  or  a  Mustang  would  do  much  better.  (The 
author  wanted  the  Aston  Martin  from  the  movie  "Goldfinger."  You  know:  The  one  with 
the  ejection  seat,  automated  license  plates  and  electronic  tracking.)  On  the  professional 
military  level,  the  Services  and  agencies  fall  into  the  same  trap.  There  are  things  we  need,  but 
many  more  things  we  want.  Why  settle  for  tanks,  ships  and  aircraft  if  we  could  have  cloaking 
devices,  The  Death  Star,  Mr.  Fusion  and  phasers? 

One  way  to  look  at  this  conundrum  is  to  see  the  difference  between  "desirements"  and  requirements.  The  word 
"desirement"  is  new.  You  cannot  find  it  in  most  published  dictionaries.  The  online  dictionaries  define  "desirement"  as 
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something  desired  but  not  absolutely  required.  Unfortunately, 
the  word  "requirement"  means  different  things  to  different 
people.  As  the  Defense  Acquisition  University  (DAU)  develops 
and  teaches  classes,  faculty  members  hear  much  about  "'Big 
R'  Requirements"  versus  "'little  r'  requirements"  and  volumes 
about  "requirements  creep."  The  challenge  is  how  to  turn  de- 
sirements  into  requirements.  How  can  requirements  manag¬ 
ers  make  the  case  that  something  is  absolutely  required? 

There  are  several  schools  of  thought.  Some  contend  that  a  re¬ 
quirement  is  not  a  requirement  until  it  is  funded.  Others  argue 
that  a  requirement  is  nothing  until  staffing  is  complete  and 
the  appropriate  authorities  validate  it.  Still  others  contend  that 
requirements  can  exist  only  under  a  Program  of  Record  where 
there  is  overlap  between  the  three  Department  of  Defense 
(DoD)  management  systems  of  requirements,  acquisition  and 
funding.  The  most  confounding  approach  is,  "The  President/ 
General/Admiral  wants  it." 

Over  the  course  of  many  classes  and  Mission  Assistance  ef¬ 
forts,  the  DAU  requirements  faculty  contends  that  a  require¬ 
ment  has  the  support  of  a  continuing  process  of  analysis.  A  de- 
sirement  lacks  such  objective  analysis.  To  begin  the  necessary 
objective  analysis,  managers  must  understand  the  level  of  the 
requirement.  Next,  a  Capability  Based  Analysis  (CBA)  must 
begin  the  intellectual  support  behind  the  requirement.  Finally, 
requirements  must  evolve  and  adapt  to  changing  threats  and 
to  lessons  learned  during  development.  Throughout  this  evolu¬ 
tion,  requirements  managers  and  program  offices  must  keep 
the  requirements  focused.  Everyone  must  avoid  the  messy, 
time-consuming  and  expensive  changes  everybody  calls  re¬ 
quirements  creep. 

Different  Levels  of  Requirements 

On  the  grandest  scale,  decision  makers  should  ask:  How  can 
we  prevent  any  conflict?  How  can  we  turn  potential  enemies 
either  into  noncombatants  or  (better  still)  into  friends?  At  the 
extreme  level,  DoD  has  two  essential  requirements: 

•  Neutralize  the  enemy. 

•  Protect  friendly  forces  and  noncombatants. 

Essentially,  in  combat  we  want  the  enemy  defeated  and  all 
of  our  troops  and  all  of  our  friends  to  come  home  unharmed. 
Achieving  these  two  overriding  goals  gets  complicated  quickly. 
How  do  we  find  and  identify  the  enemy?  What  do  we  need 
to  know  about  the  enemy's  intent  and  capability?  How  do 
we  determine  that  intent  and  capability?  What  means  do  we 
have  to  defeat  the  enemy?  How  do  we  communicate  with  our 
forces?  What  steps  will  protect  our  forces,  our  allies  and  the 
noncombatants?  How  do  we  get  ourselves  and  our  equipment 
into  the  fight  and  then  back  home? 

Raising  such  questions  helps  us  identify  different  levels  of  re¬ 
quirements.  The  "Big  R  Requirements"  include  identifyingthe 
mission  and  answering  the  broad  questions  above.  These  "Big 
R  Requirements"  lead  to  "small  r  requirements"  that  specify 


the  capabilities  our  troops  need  to  accomplish  various  mis¬ 
sions  in  diverse  operating  environments.  For  example,  what 
range,  payload  and  speed  do  transport  aircraft  need  either 
to  respond  to  a  crisis  or  to  resupply  a  sustained  effort?  What 
meets  the  military  utility  as  opposed  to  excess,  surplus  and 
overpriced  capability  frequently  derided  as  "goldplating"? 

Start  with  Analysis— The  CBA 

So  how  does  a  manager  turn  that  desirement  into  a  require¬ 
ment?  First,  recognize  the  difference  between  the  desirement 
("I  want  a  new  tank/ship/airplane/missile")  and  a  required 
capability  ("We  need  to  resupply  our  troops").  The  thought 
progression  usually  goes  through  four  steps: 

•  What  do  we  want? 

•  What  do  we  need? 

•  What  do  we  need  to  be  able  to  do? 

•  What  can  we  afford? 

Notice  how  these  steps  start  with  a  question  centered  on  some 
hardware  or  service  and  then  move  to  a  capability.  The  thought 
process  begins  with  "we  want  something  new,"  considers  the 
essential  "what  we  need,"  and  finally  recognizes  the  capability 
with  a  statement  such  as,  "We  need  to  determine  the  enemy's 
intent."  The  process  must  return  to  feasible  solutions  when  we 
face  the  budgetary  limits.  The  DoD  has  a  huge  budget,  but  we 
cannot  spend  all  that  money  on  just  one  thing. 

Good  analysis  to  support  this  thought  process  becomes  simple 
and  complicated  at  the  same  time.  The  steps  are  straight¬ 
forward  and  repeatable.  However,  each  problem  has  unique 
elements  and  technical  challenges.  Diverse  technical  problems 
call  for  subject-matter  expertise  from  different  disciplines  with 
different  terminologies,  different  priorities  and  different  points 
of  view.  Here  is  where  leadership  and  experience  count.  An 
analysis  team  leader  must  know  the  steps,  get  the  necessary 
support  and  schedule  everything  to  provide  a  timely  answer. 

At  the  very  beginning,  the  leader  and  the  analysis  team  must 
identify  the  mission  or  problem  the  analysis  must  address. 
To  keep  things  on  track,  everyone  must  agree  on  the  study 
scope:  Is  this  analysis  a  complicated  new  mission  area  or  a 
straightforward  recapitalization  of  aging  equipment?  Are  there 
previous  studies  that  help  this  effort?  How  much  rigor  must 
this  team  put  forth  to  prove  that  its  analysis  presents  essential 
requirements  and  not  just  documented  desirements? 

Once  the  team  determines  the  study's  preliminary  needs,  the 
analysis  identifies  the  needed  capabilities,  the  capability  gaps, 
and  the  operational  risks  on  a  prioritized  list.  Most  teams  face 
the  same  questions:  What  do  we  need  to  do  that  we  cannot  do 
now?  What  do  we  need  to  do  better?  What  are  the  problems 
and  the  risks? 

In  the  final  CBA  step,  the  team  considers  alternative  solu¬ 
tions.  Any  action  assumes  associated  costs  and  often  initi¬ 
ates  risk.  Perhaps  it  is  smarter  to  do  nothing  at  all.  If  too  much 
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The  warfighter— the  man  or 
woman  who  goes  into  harm's  way — 
has  every  imperative  to  expect  much 
of  us  as  requirements  managers, 
program  managers,  and  resource 
specialists. 


risk  emerges  from  doing  nothing,  the  next 
consideration  is  a  nonmateriel  solution. 

Perhaps  changing  Doctrine,  Organiza¬ 
tion,  Training,  Leadership,  Personnel, 

Facilities  or  Policy  can  solve  the 
capability  gap  problem.  Perhaps 
DoD  does  not  need  to  develop 
anything  new,  but  rather  take 
a  nondevelopmental  approach 
by  ordering  more  of  an  existing 
weapon  or  system.  The  acronym 
DOTmLPF-P  sums  up  this  overall 
non-materiel  approach— Doctrine, 

Organization,  Training,  materiel.  Lead¬ 
ership  (education),  Personnel,  Facilities 
or  Policy  (DOTmLPF-P).  The  m  is  not  capi¬ 
talized  because  it  represents  nondevelopmental 
hardware,  which  differentiates  it  from  developing  some¬ 
thing  new. 

The  final  alternative  is  to  develop  a  new  system  or  a  new 
technology.  Developing  something  new  almost  always  is  ex¬ 
pensive.  Under  typical  tight  budgets,  assessment  teams  must 
wonder  when  to  consider  the  cost  of  a  particular  solution.  The 
DoD  management  systems  wisely  separate  requirements  gen¬ 
eration  from  systems  acquisition.  Rather  than  have  the  CBA 
team  worry  about  costs,  the  thinking  today  is  that  the  require¬ 
ments  team  members  are  not  cost  or  development  experts. 
The  essential  CBA  task  is  to  identify  the  problems  and  the 
alternative  solutions.  Let  the  acquisition  experts  develop  the 
cost  estimates  so  the  decision  makers  have  the  most  credible 
information.  This  approach  also  helps  avoid  the  temptation 
to  ignore  a  capability  gap  because  the  solution  may  be  too 
expensive. 

The  CBA  Is  Just  the  Beginning 

The  product  of  a  CBA  can  be  either  an  Initial  Capabilities 
Document  (ICD)  or  a  DOTmLPF-P  Change  Recommendation 
(DCR).  The  ICD  supports  developing  a  materiel  solution;  a  ma¬ 
teriel  solution  usually  calls  for  additional  nonmateriel  changes 
such  as  new  facilities  and  new  training  procedures.  Hence,  a 
new  materiel  development  usually  has  a  supporting  ICD  and  a 
supporting  DCR.  If  the  CBA  recommends  a  nonmateriel  solu¬ 
tion,  a  DCR  will  suffice. 

Completing  the  CBA  does  not  finish  analysis  or  requirements 
development.  Arguably,  analysis  never  is  finished  because  re¬ 
quirements  managers  must  keep  refining  those  requirements 
to  respond  to  changes  in  threats,  to  apply  lessons  learned  dur¬ 
ing  system  development,  and  to  prevent  requirements  creep. 
The  requirements  listed  in  the  ICD  usually  have  a  minimum 
value.  Subsequent  requirements  documents,  the  Capabilities 
Development  Document  (CDD)  and  the  Capabilities  Produc¬ 
tion  Document  (CPD),  propose  refined  capability  require¬ 
ments  in  the  form  of  Key  Performance  Parameters  (KPPs), 
Key  System  Attributes  (KSAs)  and  Additional  Performance 
Attributes  (APAs). 


The  specifics  of  the  KPPs,  KSAs  and  APAs  can  get  programs 
into  trouble  when  operational  considerations  lead  to  derived 
requirements.  For  example,  an  aircraft  may  have  a  require¬ 
ment  to  operate  off  an  aircraft  carrier.  Carrier  operations  limit 
aircraft  weight  and  size.  The  one  requirement  for  carrier  op¬ 
erations  now  leads  to  the  two  additional  requirements  to  limit 
aircraft  weight  and  limit  aircraft  size.  A  vivid  example  involves 
a  missile  that  needs  to  fly  at  a  very  high  Mach  number.  High 
speeds  mean  high  temperatures.  High  temperatures  mandate 
expensive  materials  such  as  titanium.  The  need  to  fly  at  a  high 
Mach  leads  to  a  derived  requirement  that  the  development 
contractor  must  make  the  missile  out  of  titanium  or  something 
even  more  exotic.  (Unobtanium,  anyone?) 

The  great  risk  in  both  examples  is  that  the  requirements  man¬ 
agers  and  the  program  managers  may  overlook  alternatives 
and  compromises.  Revised  operational  concepts  could  allow 
for  different  carrier-based  aircraft  or  mission  profiles  that  do 
not  involve  carrier  operations.  A  slower,  cheaper  missile  would 
allow  less  research  and  development,  simpler  test  and  evalua¬ 
tion,  and  more  production.  It  is  all  too  easy  to  make  the  illogical 
leap,  "The  user  needs  a  high  Mach  number.  That  means  the 
user  requires  titanium.  Titanium  is  a  requirement."  What  mat¬ 
ters  here  is  the  operational  capability.  In  this  example,  the  user 
asked  for  high  speed;  the  user  did  not  tell  the  developer  how  to 
achieve  that  high  speed.  The  need  for  high  speed  may  not  be 
as  important  as  other  considerations  such  as  accuracy,  avail¬ 
ability  and  reliability.  Requirements  managers,  program  offices 
and  developers  must  be  open  to  these  kinds  of  tradeoffs. 

A  Good  Requirement’s  Characteristics 

As  systems  development  progresses,  the  requirements 
documents  support  the  succeeding  milestones  and  the  re¬ 
quirements  become  more  specific.  Ideally,  the  requirements 
manager  works  with  the  program  office  to  apply  the  les¬ 
sons  learned  from  the  development  phases.  These  lessons 
learned  should  combine  with  the  results  of  the  analysis  so  the 
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requirements  describe  the  overriding  military  or  operational 
utility.  Good  requirements  avoid  the  common  pitfalls  of  being 
too  vague,  subjective,  expensive  and  restrictive. 

Bad  requirements  can  be  vague,  subjective,  expensive 
and  restrictive.  Effective  requirements  have  the  following 
characteristics: 

•  Measurable— The  requirement  must  be  quantifiable  and 
verifiable  through  inspection,  analysis,  demonstration, 
simulation  or  testing. 

•  Attainable— The  requirement  must  be  feasible  and 
achievable  with  today's  technology,  the  available  time, 
and  the  available  money. 

•  Necessary— The  requirement  must  be  necessary  to  ac¬ 
complish  the  mission;  there  is  no  room  for  the  frivolous  or 
the  "nice  to  have." 

•  Correct— The  requirement  must  accurately  describe  the 
capability  the  program  office  and  the  developer  need  to 
deliver. 

•  Unambiguous— The  requirement  is  not  open  to  interpreta¬ 
tion;  everyone— from  the  requirements  shop,  the  program 
office,  and  the  contractors— can  agree  on  what  to  develop 
and  deliver. 

•  Orderly— Requirements  are  clearly  prioritized  so  the  pro¬ 
gram  office  can  make  trade-offs. 

•  Organized— Requirements  are  grouped  into  categories  to 
avoid  duplication,  inconsistencies  and  contradictions. 

•  Results-Oriented— The  requirements  are  based  on  opera¬ 
tional  capabilities;  they  describe  what  the  system  needs 
to  do. 

Clear,  effective  requirements  allow  the  requirements  manag¬ 
ers  to  work  with  the  systems  engineers  to  develop  specifica¬ 
tions  for  the  contractors.  Then  industry  can  develop,  produce 
and  support  the  equipment  the  warfighter  needs. 

Bring  New  Systems  Together 

At  every  level  we  must  remember  how  each  Service  and  each 
agency  is  part  of  a  greater  whole.  Many  capabilities  come  to¬ 
gether  to  serve  the  warfighter  and  to  defend  the  nation.  As 
technology  moves  forward,  new  technologies  often  have  the 
potential  to  do  what  once  appeared  impossible.  Our  ability 
to  innovate  and  to  apply  technology  is  among  our  greatest 
strengths.  The  great  challenge  remains  communicating  what 
the  warfighter  needs  to  do  and  what  the  acquisition  system— 
with  its  laboratories,  engineers  and  contractors— can  provide 
on  cost,  on  schedule,  with  worthy  performance. 

None  of  these  communications  steps  are  easy.  The  abilities  to 
innovate  and  to  imagine  often  begin  tortuous  processes  to  turn 
ideas  into  capabilities.  The  teamwork  of  multiple  disciplines 
must  come  together  to  develop  results.  The  communications 
and  development  processes  become  rigorous  and  time-con¬ 
suming  because  we  expect  so  much  from  ourselves,  from  our 
partners,  and  from  the  warfighter.  In  turn,  the  warfighter— 
the  man  or  woman  who  goes  into  harm's  way— has  every 


imperative  to  expect  much  of  us  as  requirements  managers, 
program  managers,  and  resource  specialists. 

We  probably  all  have  stories  about  how  someone  in  our  chain 
of  command  expressed  a  desirement  and  expected  us  to  make 
it  happen.  We  have  all  heard  stories  of  how  analysis  gave  an 
answer  the  boss  did  not  want.  Nevertheless,  many  steps  must 
combine  the  contributions  from  many  disciplines  to  complete 
sound  analysis,  document  the  need  for  new  or  for  improved 
capabilities,  get  the  necessary  documentation  validated,  and 
get  a  new  effort  funded.  A  subjective  desire  for  something  new 
must  evolve  into  a  sound  objective  requirement  as  we  develop 
new  capabilities  that  continue  to  allow  our  forces  to  prevail. 

Experienced  leaders  know  that  good  communications  takes 
time  and  effort.  Good  communications,  solid  analysis  and  in¬ 
sight  into  the  potential  pitfalls  remain  at  the  center  of  any  effort 
to  turn  desirements  into  requirements.  & 

The  author  can  be  contacted  at  charles.court@dau.mil. 


MDAP/MAIS  Program  Manager  Changes 


With  the  assistance  of  the  Office  of  the  Secretary  of 
Defense,  Defense  AT&.L  magazine  publishes  the  names 
of  incoming  and  outgoing  civilian  and  military  program 
managers  for  major  defense  acquisition  programs 
(MDAPs)  and  major  automated  information  system 
(MAIS)  programs.  This  announcement  lists  a  recent 
change  of  leadership. 

Navy/Marine  Corps 

CAPT  Robert  Croxson  relieved  CAPT  Andrew  Williams 

as  program  manager  for  Multifunctional  Information 
Distribution  System  (PMA/PMW-101)  on  May  20,. 

Steven  Pinter  relieved  Gary  Prosser  as  program  man¬ 
ager  for  Medium  &  Heavy  Tactical  Vehicles  (PMM-206) 
on  June  28. 

Air  Force 

Col  Don  Hill  relieved  Col  Gregg  Kline  as  program  man¬ 
ager  for  the  OPS  C2  System  Program  on  May  22. 

Col  William  Bell  relieved  Col  Patrick  Burke  as  program 
manager  for  the  Munitions  Sustainment  program  on 
June  28. 

Col  Scott  Jones  relieved  Col  Ryan  Britton  as  program 
managerforthe  Intercontinental  Ballistic  Missile  (ICBM) 
Systems  program  on  June  30. 

Col  Timothy  Bailey  relieved  Col  Edward  Koslow  as  pro¬ 
gram  manager  for  the  F-15  System  program  on  June  30. 
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